The present invention relates to a method of detecting a memory leak causing portion generated in executing a program described in a programming language of Java language or the like capable of tracking a data relationship with regard to a plurality of data stored in a memory of a computer and an execution program thereof.
As one of causes by which a computer program does not achieve a performance as expected, there is pointed out a phenomenon referred to as memory leak in which a data memory region used in the program continues to increase. Normally, data generated in executing a program is arranged at a memory region referred to as a heap region. The heap region is a kind of a memory region used in executing a program and is utilized for storing data a size of a storage region of which is dynamically determined such as data inputted to the program. In storing data, it is necessary to secure a storing region based on a size of data to be stored and when the data becomes unnecessary, an operation of releasing the ensured storage region is needed. When the operation of releasing the ensured region is not executed properly or when data of unfreed area become invisible from the executing system, there is generated a state in which the memory region used by the program continues to increase, that is, the memory leak.
Patterns of generating the memory leak can be classified broadly into two kinds. One is a memory leak happens in a language which explicitly executes an operation of releasing the region as in C language or C++ language and another is a memory leak happens in a language which implicitly releases the region as in Java language (Java is a trademark or a registered trademark of Sun Microsystems, Inc. in USA and other countries).
In a case of a language explicitly instructing release of region in the heap region as in C language or C++ language, a memory leak may occur due to a deficiency in release of region. Further, there may also occur a memory leak by disappearance of a reference to the data storage region ensured in the heap region when other reference is assigned erroneously to a field in the heap region holding the reference to the data storage region before release of the region. As a method of resolving the memory leak, there is a technology of monitoring allocation and release of a data region in executing a program, regarding a region which is not released as data causing memory leak and specifying a portion of memory leak as described in RATIONAL Software, “Purify: Fast Detection of Memory Leaks and Access Errors”, Purify Product Information White Papers. (hereinafter, referred to as Non-patent Document 1) and a technology for preventing memory leak by static pointer analysis in compiling as described in David L. Heine and Monica S. Lam, “A Practical Flow-Sensitive and Context Sensitive C and C++ Memory Leak Detector”, Proc. of the ACM SIGPLAN 2003 conference on Programming language design and implementation, 2003 (hereinafter, referred to as Non-patent Document 2).
On the other hand, in the case of a programming language for implicitly executing data region release as in Java language, a garbage collection function of recovering an unnecessary data storing region can frequently be utilized. A program by Java language is temporarily converted into a program by an intermediate language and the program by the intermediate language is executed on a virtual machine. According to the program by Java language, release of the memory region is not designated but unnecessary data is collected by the garbage collection function provided to the virtual machine. The above-described implicit release of the data region means that, release of the memory region is not designated in the program per se by Java language but the region of data is released by the garbage collection function and the like. The garbage collection function is a function of collecting data deviated from the data reference relationship and therefore, when there is generated a reference for unnecessary data which is not anticipated by a programmer due to a failure in programming, data does not become an object of collecting by the garbage collection function and this causes a memory leak by which the necessary data continues to increase in the memory. That is, according to the garbage collection function, even in the case of data which is not needed for a user, the data having the data reference relationship does not become the object of data recovery.
As described above, in the case of a programming language as Java language, the operation of releasing the data region is not explicit and therefore, it is extremely difficult to specify the leak causing portion in the program, and the method of detecting a memory leak causing portion used for C language or C++ language cannot be used. Therefore, when memory leak is suspected with regard to a program by Java language, there have been developed a technology of indicating a data group whose an amount of memory usage is increased in the memory as described in, for example, U.S. Pat. No. 6,167,535 (hereinafter, referred as Patent Document 1), or U.S. Pat. No. 6,370,684 (hereinafter, referred to as Patent Document 2), a method of assisting to discover a portion of generating memory leak by illustrating a reference relationship with regard to a certain data selected from a data group as described in Wim De Pauw and Gary Sevitsky, “Visualizing Reference Patterns for Solving Memory Leaks in Java”, Proc. of the 13th European Conference on Object-Oriented Programming, 1999 (hereinafter, referred to as Nonpatent Document 3).
With regard to memory leak generated in executing a program using a language which executes release of the data region implicitly, such as Java language, according to the background arts, only the data group whose amount of memory usage is increased in the memory as in Patent Documents 1, 2, mentioned above, or a reference relationship with regard to a certain data selected from the data group is illustrated as in Nonpatent Document 2, mentioned above, and further, in many cases, data in which memory leak is suspected is not frequently single, further, there are an enormous number of the reference relationship of data and therefore, there poses a problem that an investigation on a source of producing memory leak becomes a very difficult operation.